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(54) Improvements relating to data distribution 



(57) A method of distributing performance data con- 
cerning a plurality of subjects (such as stock market 
companies) from a distribution site to a user site is de- 
scribed. The method comprises storing gathered per- 
formance data concerning each of the subjects in a cen- 
tral database, where the storing step comprises storing 



the gathered data to form a contiguous sequential block 
of historical data for each subject. The method also in- 
cludes, on request from the user, providing a stream of 
historical data from the blocks in the central database 
such that a ticker tape of a plurality of graphical historical 
data charts can be displayed at the user's site, automat- 
ically and without user interaction. 
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Description 

[0001 ] The present invention concerns improvements 
relating to data distribution and more particularly, though 
not exclusively, to a method of and system for distribut- 
ing updated performance data to customers over a com- 
munications network such as the Internet. The data is 
typically daily updated stock market (securities) infor- 
mation obtained from different data vendors. The data 
can be accessed via a Graphical User Interface (GUI) 
in the form of an interactive ticker tape. 
[0002] Stock market results generate vast amounts of 
financial data which are indicative of the performance of 
the traded securities each day. This performance infor- 
mation is distributed in various ways to data gathering 
companies who in turn supply it to subscribing custom- 
ers requiring the information. Electronic performance 
data vendors provide dedicated communication links in- 
to their databases for the data gathering companies to 
have direct access to the performance information they 
require. More recently, with the advent of Wide Area 
Networks (WANs), such as the Internet, it has been pos- 
sible for data gathering companies to access several 
electronic performance data vendors' databases and al- 
so to distribute performance data to subscribing custom- 
ers by use of general purpose communications equip- 
ment. 

[0003] Financial performance data provided by each 
electronic performance data vendor presents a huge 
mass of information which can be provided to the cus- 
tomer. It is not practical to provide all of this data to the 
user at once because of the limited amount of data that 
can be presented on the user's screen and also because 
this would be highly inefficient (providing Information 
that is of no interest to the customer). Data gathering 
companies often divide this mass of data into smaller 
sets of grouped data and, for example with the Internet, 
the groups of data are presented through a hierarchical 
web page structure. The customer can then be present- 
ed with different web pages showing different data. For 
example, the customer can be presented with lists of 
current stock prices on one page and by selecting a link 
from a specific security, a chart of historical performance 
data concerning the selected subject can be generated 
on the next web page. 

[0004] The performance data received by the custom- 
er is often displayed in a table format showing each se- 
curity and how it has performed since its close of busi- 
ness the previous day. Typically, there is a positive or 
negative movement number adjacent the displayed cur- 
rent security value (stock price for example) showing the 
size and direction of movement of the security value 
since the last update. 

[0005] Another way of displaying the security values 
is to use a ticker tape. By scrolling the received security 
values (and their movement numbers) across a portion 
of the customer's screen, typically a frame, it is possible 
for the customer to view a variable size of performance 
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data without altering the format of the screen. Also, as 
only a portion of the screen is taken up by the ticker tape, 
the customer can use the rest of the screen for other 
applications but still keep an eye on movements of se- 

5 lected securities. 

[0006] A typical application of this ticker tape for dis- 
playing securities performance data is described in WO- 
A-99/16181. Here the performance information is ob- 
tained on a portable mobile phone via the Internet using 

10 a WAP (Wireless Application Protocol). 

[0007] The most common application of ticker tapes 
has been to display alphanumeric data relating to the 
real-time performance of securities. Accordingly, the 
use of ticker tape displays has been restricted to the dis- 

15 play of only basic text information due to the relatively 
short time which is available to display each new item 
of the ticker tape as it moves. 
[0008] The present invention resides in an improve- 
ment in the known methods and systems for distributing 

20 updates of performance data. The inventor has appre- 
ciated that it is advantageous to provide to the customer 
with a stream of historical data relating to the perform- 
ance of a subject (security) such that it can be displayed 
graphically in a ticker tape format. This information can 

25 give the customer an immediate appreciation of trends 
in the performance of the stock and whether or not It is 
advantageous to take some action (buy or sell stock) in 
view of this. 

[0009] According to one aspect of the present inven- 
30 tion there is provided a method of distributing perform- 
ance data concerning a plurality of subjects from a dis- 
tribution site to a user site, the method comprising: stor- 
ing gathered performance data concerning each of the 
subjects in a central database, wherein the storing step 
35 comprises storing the gathered data to form a contigu- 
ous sequential block of historical data for each subject; 
and on request from the user, providing a stream of his- 
torical data from the blocks in the central database such 
that a ticker tape of a plurality of graphical historical data 
40 charts can be displayed at the user's site, automatically 
and without user Interaction. 

[0010] The benefit of this graphically displayed histor- 
ical data is that the customer can immediately, without 
any user interaction, place the daily price variation of 

45 the security into the context of a medium term price chart 
in order to gain a broader prospective of the price action 
within a trend. In these cases, the specific current value 
of the performance data is also displayed with each his- 
torical data chart. 

50 [001 1 ] For the avoidance of doubt, the term perform- 
ance data is intended to mean data which represents 
the current values of financial securities which can fluc- 
tuate in value over a given time period, such as stocks, 
shares, funds and bonds. Also the term historical data 

55 is intended to mean data that represents the history of 
the performance data over a period of time. As such, the 
term historical data is intended to cover more than just 
a single value which is representative of the penultimate 
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value of the performance data such that an indication of 
whether the stock has increased or decreased can be 
determined. 

[001 2] It is to be appreciated that the term ticker tape 
as used herein has its normal meaning of a series of 
discrete data items being scrolled across part of a 
screen. This stream of data is moved at a rate at which 
the data can be read by a user. 
[001 3] By providing the historical data graphically, the 
amount of information provided to the user is advanta- 
geously maximised within a minimum space allocation. 
This results in a further advantage in that the user can 
then access the data via a GUI (Graphical User Inter- 
face) which is in the form of a ticker tape. 
[0014] The rate of generation of the graphical histor- 
ical data charts may correspond to the speed of move- 
ment of the ticker tape displayed at the user's site. This 
is the minimum rate required to sustain an apparently 
real-time display at the user's site. 
[0015] The storing step may comprise storing the 
gathered performance data in the historical data blocks 
such that each block is partitioned according to prede- 
termined different time periods. Preferably, the historical 
data blocks are each partitioned in daily, weekly, month- 
ly and yearly time periods. The advantage of this is that 
it speeds up data retrieval from the central database be- 
cause the data access primitives can sample the mass 
of historical data to extract only those values at the ap- 
propriate partitions rather than going through all of the 
stored data, in order to construct the appropriate histor- 
ical data chart. 

[0016] The method may further comprise gathering 
performance data at a central site and subsequently up- 
dating the distribution site with the gathered data. In this 
way, a distributed data system can advantageously be 
implemented the responsibility of gathering the raw data 
at regular time intervals being removed from the data 
supplying function of the distribution site. 
[0017] The gathering step may comprise download- 
ing performance data from a plurality of electronic data 
vendors where two or more data vendors have different 
data distribution protocols, and for each data vendor 
having a different data distribution protocol, the method 
may further comprise implementing an appropriate 
communications protocol for downloading performance 
data from each data vendor. This enables the central 
site to process data from different data vendors even if 
they employ different communication protocols. 
[001 8] The gathering step preferably comprises con- 
solidating, integrating and reformatting gathered per- 
formance data from the plurality of data vendors. In or- 
der to place the data into a standard format, it is neces- 
sary to strip the gathered data down to its raw data and 
then reformat it and combine it with other data. The uni- 
formity of the stored data is essential for efficient further 
distribution of the data to users. 
[001 9] As mentioned previously, the providing step is 
initiated on demand and preferably this is by a data re- 
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quest from the user. The request may include identity 
information identifying the user, and the method may fur- 
ther comprise accessing a user configuration file de- 
scribing a required data configuration for the identified 
5 user, or for a newly identified user, creating a new user 
configuration file set to a default configuration. In this 
way, advantageously information about the user can be 
stored at the distribution site and be used to configure 
the same user's GUI when he or she next connects to 
10 the distribution site. 

[0020] In an embodiment of the present invention, the 
communications network is the Internet and the identity 
information comprises a cookie file initially sent to the 
user. This is a simple way of using existing technology 
is to provide the desired user information, 

[0021] The method may further comprise storing the 
user configuration files and identity information in a re- 
lational customer database and accessing the same us- 
ing Structured Query Language. In this way, a multitude 
of customer information can be collected and accessed 
in an intelligent and fast manner. 
[0022] The providing step preferably further compris- 
es sending a user configuration file to its user together 
with a data handling function arranged to present to the 
user the historical data in accordance with the user con- 
figuration file. Previously stored user preferences can 
be sent to the user together with a program for config- 
uring the user's GUI to handle the download of informa- 
tion and its presentation, without user interaction. 
[0023] In an embodiment of the present invention, the 
communications network is the Internet and the data 
handling function comprises an applet. This is also a 
simple, yet powerful, way of implementing the handling 
function using existing technology. 
[0024] Preferably, the data handling function config- 
ures a user's screen according to the information in the 
configuration data file and requests specific historical 
data from the central database for immediate display. 
As mentioned previously, this automises the distribution 
process. 

[0025] The step of using the handling function may 
comprise arranging the historical data into charts and to 
display simultaneously a plurality of charts arranged as 
an endless stream of moving graphical images forming 
a ticker tape on a user's screen. Ticker tape type dis- 
plays of information are a neat way of displaying infor- 
mation at a readily comprehensible rate within a rela- 
tively small section of a user's screen. Use of the han- 
dling function to perform this function increases the 
functionality of the handling function thereby minimising 
the requirement for additional separate software mod- 
ules. 

[0026] The step of using the handling function may 
comprise configuring the remote user's screen to control 
the amount and type of performance data to be dis- 
played. This advantageously acts as a filter which pre- 
vents the limited amount of information that is continu- 
ally being displayed to the remote user from being irrel- 
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evant and of little or no interest. 
[0027] The storing step which updates the central da- 
tabase is preferably carried out on a daily basis. This 
provides a basic unit of historical data for storage in the 
central database and advantageously corresponds to 
the conventional time periods when prices of securities 
are compared. The central site is often being updated 
from data vendors all over the world resulting in almost 
a continuous gathering procedure. However, due to the 
distributed nature of the system, the storing step at dis- 
tribution site need only be carried out on a daily basis 
to provide the required updating of the central database. 
[0028] According to another aspect of the present in- 
vention there is provided a system for distributing per- 
formance data concerning a plurality of subjects from a 
distribution site to a user site, the system comprising: a 
central database of performance data relating to each 
of the plurality of subjects, storing means for storing 
gathered performance data concerning each of the sub- 
jects in the central database, the storing means being 
arranged to store the data to form a contiguous sequen- 
tial block of historical data for each subject; and read 
out means arranged to provide, on request from the us- 
er, a stream of historical data from the blocks in the cen- 
tral database such that a ticker tape of a plurality of 
graphical historical data charts can be displayed at the 
user's site, automatically and without user interaction. 
[0029] The present invention also extends to a con- 
figurable ticker tape interface for providing performance 
data regarding a plurality of subjects stored in a remote 
database, the ticker tape interface being arranged to be 
configurable by the user to specify a subset of the plu- 
rality of subjects, to obtain current performance data and 
historical data from the remote database regarding the 
selected subset of subjects, and to generate user-con- 
trolled movable icons of the ticker tape interface, each 
icon representing the current performance data and his- 
torical data for selected subject in a graphical format. 
[0030] Ticker tape displays are a neat way of display- 
ing information at a readily comprehensible rate and al- 
so in a way that allows the user to view something else 
on screen. A limitation with the use of ticker tape dis- 
plays has been that only a limited amount of alphanu- 
meric data has been displayable to the user. The 
present invention utilises the advantages of the ticker 
tape format and increases the amount of information 
that can be provided to the user by using graphical icons 
representing the mass of historical data for each sub- 
ject. Control of how the ticker tape interface is config- 
ured enables the user to predetermine the type of per- 
formance data that they which to be shown. This com- 
bination of moving graphical icons and preselection of 
subject types provides a synergistic effect in that the 
ticker tape interface can provide access to an enormous 
amount of different performance data whilst still main- 
taining the relevance of that information to the user's re- 
quirements. 

[0031] The present invention can also be considered 
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to be a graphical user interface comprising: processing 
means for obtaining updated information from a distri- 
bution database regarding a plurality of subjects and 
processing the obtained information to display a moving 

s set of graphical images, each image representing cur- 
rent performance data and historical data for a given 
subject; and selecting means for creating a user selec- 
tion, the selecting means being arranged to configure 
the processing means to obtain information for a selec- 

10 tion of the plurality of subjects stored in the distribution 
database. 

[0032] Preferably, the GUI further comprises selec- 
tion means, operable by the user, for selecting a time 
period of historical data, smaller than that stored in the 
'5 distribution database for a given subject, which is to be 
displayed in the set of graphical images. Accordingly, 
the user can select the time frame which is of interest 
for the historical data of each security that is to be graph- 
ically displayed. This is typically between one and five 
years. 

[0033] The GUI may further comprise control means, 
operable by the user, for altering the movement of the 
set of graphical images. As each of the graphical images 
should be able to be read by the user, and different users 
have different reading speeds, this feature advanta- 
geously allows the user to set the movement of the set 
of graphical images (scrolling speed of a ticker tape for 
example) to their desired comfortable reading speed. 
[0034] Preferred embodiments of the present inven- 
tion will now be described by way of example with ref- 
erence to the accompanying drawings. In the drawings: 

Figure 1 is a schematic block diagram of an updated 
performance data distribution system embodying 
the present invention; 

Figure 2 is a flow diagram showing a method of up- 
dating the market database shown in figure 1 with 
information from data vendors; 

Figure 3 is a schematic diagram of the performance 
distribution system of Figure 1 showing the data 
flow from the data vendors to the customers over 
the Internet; and 

Figure 4 is a screen image of a ticker tape graphical 
user interface provided at a customer's site in Fig- 
ure 3. 

[0035] Referring now to Figure 1 , there is shown an 
updated performance data distribution system 10 em- 
bodying the present invention. The system 1 0 is config- 
ured to gather, on a dairy basis, performance data relat- 
ing to the current values of securities such as stocks, 
funds and shares from stock markets all over the world. 
This current data can then be collated and supplied to 
customers together with additional historical data de- 
rived from the current data. Given the number of sub- 
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jects (stocks, funds and shares for different companies) 
to be covered and the volume of historical data for each 
subject (typically daily information going back several 
years), the historical data for each subject is presented 
graphically as an element of a ticker tape as is described 
in detail in hereinafter. 

[0036] The system 10 comprises a central data 
processing site 12 that is connected to three data ven- 
dors 1 4 by different communication channels. Data ven- 
dor A 16 is connected directly to the central data 
processing site 12 through a direct telecommunication 
line 18. Data vendor B 20, who may be located in a dif- 
ferent country, is connected to the central data process- 
ing site 12 via the Internet 22. Data vendor C 24 is con- 
nected to the central data processing site 12 directly 
through a public telephone network 26 such as a PSTN 
or ISDN. 

[0037] The central data processing site 12 thus re- 
ceives data from a plurality of sources 14. The received 
data is cleaned up, collated, integrated and stored within 
the central data processing site 12. The exact way in 
which this data is processed is described in detail later. 
Selected data is then distributed, in this embodiment, to 
each of four local data distribution sites 28 that may also 
be in different countries of the world. 
[0038] The central processing site 12 is coupled to a 
local data distribution site W 30 and a local data distri- 
bution site X 32 via the Internet 22. More specifically, 
local data distribution sites W and X 30, 32 are each 
servers with their own securities database hosted by a 
respective Internet Server Provider (ISP) 34, 36. Each 
of these distribution sites 30, 32 has a web page (not 
shown) which is accessible to its subscribing customers 
38 via the Internet 22. 

[0039] A local data distribution site Y 40 is directly 
connected into the Internet 22 for data communication 
with the central data processing site 1 2. This distribution 
site 40 has a local securities database for storing re- 
ceived information and provides a local host for its cus- 
tomers 42 via an Intranet or LAN (Local Area Network) 
44. The customers 42 obtain the information distributed 
to the local distribution site 40 by accessing its local web 
site 46. 

[0040] A local distribution site Z 48 is directly connect- 
ed into the public telephone network 26 for data com- 
munication with the central processing site 1 2. This dis- 
tribution site 48 has a local securities database for stor- 
ing received information and provides a local host for its 
customers 50 via an Intranet or LAN (Local Area Net- 
work) 52. The customers 50 obtain the information dis- 
tributed to the local distribution site 48 by accessing its 
local web page 54. 

[0041] The central processing site 12 comprises a 
communications manager 56, a data processing unit 58, 
a market database 60 and a market database manage- 
ment unit 62. The communications manager 56 handles 
all the data communications to and from the central 
processing site 12, namely to and from the data vendors 
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14 as well as to and from the local distribution sites 28. 
The communications manager 56 includes hardware 
and software supplied by some of the data vendors 14 
for handling each of their specific data transmission pro- 
5 tocols as well as their specific formats of data. This spe- 
cial equipment is configured to optimise the often-large 
data transfers. Others data vendors, such as data ven- 
dor B 1 6, simply provide an Internet address and a pass- 
word for accessing the data at their Internet site. 
w [0042] Different data vendors have different ways of 
supplying performance data to the central processing 
site. Performance data is broadcast by some of the data 
vendors at regular intervals to subscribers, such as the 
central processing site 12. Other performance data has 
is to be obtained on demand. Some data vendors provide 
data in real time and others provide the data as snap- 
shots on a daily basis. As the performance data from 
the different data vendors is In different formats, the data 
vendors 14 provide specific data structure specifica- 
te tions, setting out how the data will be sent, which are 
stored at the central processing site 12 and used in ex- 
tracting the desired information from the received data. 
[0043] The data processing unit 58 receives the raw 
performance data from the communications manager 
25 56 and transforms it into a uniform format. The market 
database management unit 62 takes the transformed 
data and stores it in the market database 60 in an ap- 
propriate way for ease of access. The market database 
management unit 62 also handles the retrieval of select- 
so ed performance data for transfer to the local data distri- 
bution sites 28 via the communications manager 56. 
[0044] Referring to Figure 2, the method of accumu- 
lating performance data from the different data vendors 
1 4 and storing it in the market database 60 is now de- 
35 scribed in detail. The method commences at 70 with the 
downloading of performance data from a financial data 
vendor 14 over a communications link. The perform- 
ance data is provided on hundreds of companies, funds 
and stocks from one or more markets, for example from 
40 the New York and London Stock Markets, with each dif- 
ferent stock, fund or company being considered as a dif- 
ferent subject. The different ways in which this data is 
transferred has been mentioned previously. 
[0045] The data processing unit 58 transforms the 
45 downloaded data at 72 into a standard format suitable 
for storage in a common database (the market database 
60). This procedure requires accessing the stored infor- 
mation regarding the data format used by each particu- 
lar data vendor 1 4 and using this information to strip out 
so the required information; for example the name of the 
subject and the current stock market value of its shares 
in a particular market. 

[0046] The data processing unit 58 then detects and 
corrects errors In the received data at 74. This Is carried 
55 out in a two-stage process. The first stage involves a 
computer program considering the received data and 
compiling a ranked list of potential errors. The second 
stage involves selecting likely errors for correction and 
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correcting them on the basis comparison with previously 
received correct performance data for the subject. The 
error-corrected data is then consolidated and integrated 
together at 76 for storage in the market database 60 on 
a subject by subject basis. 

[0047] The market database 60 stores the perform- 
ance data on a subject by subject basis. Prior to the re- 
ceived error-corrected data being stored, a check is car- 
ried out at 78 to determine whether the current subject, 
for which performance data is to be stored, is one which 
has an existing data entry in the database 60. This can 
be simply achieved by checking a running list of subjects 
in the database 60. If the subject is not new, then the 
existing record pertaining to this subject is located at 80 
in the market database 60 and the received perform- 
ance data for this subject is stored at 82 in that record. 
[0048] The exact manner of updating the existing data 
record in this way is dependent on the data structures 
used in the database, in this particular embodiment, 
slightly different data structures are used for different 
types of subject, stocks are different from funds for ex- 
ample. However, in general, a two-part record structure 
for each subject is used. The first part of the record struc- 
ture is a flat record of fixed size containing all the struc- 
tural information (data descriptors such as market, sec- 
tor, capitalisation, etc.) about the subject and a pointer 
to the second part of the structure. The second part is 
an array of historical performance data regarding the 
subject, storing the historical data sequentially and con- 
tiguously. 

[0049] The historical data array stores the value of the 
subject on a daily basis, daily prices of a stock for ex- 
ample, in a contiguous and sequential manner without 
any stored sums or statistics. The data Is partitioned ac- 
cording to a set of time frame periods which determine 
the granularity of the historical data namely, daily, week- 
ly, monthly and yearly. The purpose of this sequential 
storage and partitioning is to enable rapid access to and 
retrieval of selected data from the often large mass of 
historical data for a subject. For example, historical data 
over a five-year period on a daily basis is commonly 
stored in the historical data array. Also by storing the 
historical data in this way, the granularity of data retrieval 
can be handled without difficulty as the positional rela- 
tionships of the historical data is predetermined. 
[0050] Turning back to the result of the check carried 
out at 78 to determine whether the current subject, for 
which performance data is to be stored, is one which 
has an existing data entry in the market database 60. If 
the subject is new, then structural information (data de- 
scriptors such as market, sector, capitalisation, etc.) for 
each subject are determined at 83. Each data descriptor 
is simply a grouping that helps in the data retrieval stage 
when a customer 38, 42, 50 may require the retrieval of 
only particular groupings of relevant data. Then a first 
part of a two-part subject record is created at 84 in the 
market database 60; the first part is arranged to store 
the newly created structural information (data descrip- 
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tors) describing the subject. Subsequently, a historical 
array (second part of the subject record) for storing con- 
tinuous received performance data is created at 86 and 
a pointer (not shown) to this second part is added to the 
5 first part of the subject record. 

[0051] Once the subject record has been created at 
84 and 86, the received data for a given subject is then 
stored at 88 in both the first and second parts of the 
record. More specifically, the newly created data de- 
scriptors are stored in the first part and received data is 
stored at a starting position for the contiguous data in 
the historical array. Also a list bearing the names of all 
subjects may then be updated as appropriate. 
[0052] A check is then carried out at 90 to determine 
whether there is further data on any of the subjects in 
the received data that needs to be stored in the market 
database 60. If there is further data to be stored, then 
the above procedure at 78, 80, 82, 84, 86, 88 for storing 
the received information in the market database 60 is 
repeated for all of the different subjects about which in- 
formation has been received at 70. 
[0053] Once all the received data has been loaded in- 
to the market database 60, the method waits at 92 until 
a new update is required or new information has been 
received. When new information is to be obtained, the 
above-described steps of the method are repeated. 
[0054] Having accumulated the data at the central 
processing site 12, this data is then distributed to the 
local data distribution sites 28 according to the specific 
services to be provided by each local site 28. Typically, 
the central processing site 12 is run by a first company 
and the local data distribution sites 28 are run by second 
companies who pay a subscription fee to the first com- 
pany for the services provided. 
[0055] Each local site 28 has a securities database 
that has the same data structure format as the market 
database 60. Each securities database is accessible to 
its customers 38, 42, 50 through a web page 46, 54 of 
the server. Usually each securities database stores a 
copy of all of the data which is maintained in the market 
database 60 such that, if required, customers 38, 42, 50 
have access to the full range of performance data. How- 
ever, some securities databases may only retain a pre- 
determined subset of the subjects or markets stored in 
the market database 60. In these cases, the second 
companies may pay a reduced subscription fee to the 
first company. 

[0056] The way in which data is transferred from the 
local sites 30, 32 to particular customers 38 over the In- 
ternet 22 is now described by way of example. The other 
local sites 40, 48 transfer data in a different way which 
is dependant on the specific protocols implemented on 
their Intranet or LAN 44, 52. However, the principles de- 
scribed below of how data is supplied to the Internet cus- 
tomers 38 applies equally to the operation of these other 
local sites 40, 48. 

[0057] Referring now to Figure 3, flow of data from the 
data vendors 14 to the Internet customers 38 is shown 
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schematicalty. As mentioned previously, market data 
are downloaded daily 1 00 from the different data ven- 
dors 14 using specific and usually different protocols 
and technological media for each data vendor 14. As 
there are several data vendors, each providing data on 
different subjects, the downloading procedure occurs al- 
most continually. Data are consolidated, integrated and 
cleaned up 1 02 by proprietary software in the central 
processing site 12 and the received data is stored in the 
market database 60. 

[0058] A proprietary procedure 1 04 updates the local 
data distribution site 28, 30 on a daily basis with new 
performance data. The data is stored in the securities 
database 106 that is based on proprietary technology 
and is highly optimized for the storage and rapid retrieval 
of historical numerical series. As mentioned previously, 
the structure of the securities database 106 is the same 
as that of the market database 60. This data structure 
is specifically implemented to provided fast access to 
records and the historical data provided therein. Accord- 
ingly, the access primitives used to retrieve data operate 
at relatively high speeds. 

[0059] The local data distribution site 28, 30 compris- 
es a securities database server 108, communications 
server 110 and an SQL relational database 112 which 
stores customer information and customer defined data 
configurations. The communications server 110 han- 
dles the real-time communications between the custom- 
er 38 and the local data distribution site 28, 30. Further- 
more, the communications server 1 1 0 provides data ac- 
cess to the securities database 106 via the securities 
database server 1 08 and to the SQL relational database 
112. 

[0060] Each customer accesses the local data distri- 
bution site 28, 30 via an Internet browser running on 
their own computer (not shown). The data to be supplied 
from the local data distribution site 28, 30 to the custom- 
er 38 takes the form of a ticker tape 1 1 4 of charts 1 1 6 
as will be described in detail later. 
[0061] When a page or frame containing a reference 
to the ticker tape 1 1 4 Is requested by a customer brows- 
er over the Internet 22, the contents of a specific cookie 
file 1 1 8 on the customer computer is sent with the iden- 
tity of the customer (for known customers) to the local 
data distribution site 28, 30. The specific configuration 
associated with the customer identity is retrieved from 
the SQL (Structure Query Language) database 112 by 
an ASP (Active Server Page) 1 20 that makes use of an 
ADO (Active Database Object?) CO Ms (Component 
Object Models) in the communications server 1 1 0. Cus- 
tomer configuration may include an explicit set of secu- 
rity identities or a set of selection criteria. For unknown 
customers, a default configuration is generated. 
[0062] A proprietary Java applet 122 Is then down- 
loaded from the communications server 110 to the cus- 
tomer 38, together with the configuration information re- 
trieved from the SQL relational database 1 1 2. The ap- 
plet 122 interprets the configuration information, config- 
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ures the customer's display 1 24 and generates a stream 
of URLs (Universal Resource Locators) which are for- 
warded to the local data distribution site 28, 30 for each 
of the charts 116 of the ticker tape 114 to be displayed. 

s The URLs are generated sequentially as each URL that 
makes up the ticker tape 114 is to be displayed on the 
user's screen. Accordingly, the rate at which the ticker 
tape is being moved corresponds to the rate of genera- 
tion of the stream of URLs. 

w [0063] For each URL received, the communications 
server 110, through a proprietary COM (server compo- 
nent) within another ASP 126 of the communications 
server 110, interacts with the proprietary securities da- 
tabase server 1 08 and asks for the generation of a chart 

15 116. The requested charts 116 are generated in GIF 
(Graphics Interchange Format) and are downloaded as 
a sequential stream of data to the applet 1 22 at the cus- 
tomer 38. The applet 1 22 displays the requested charts 
116 on the screen 124 in the form of the moving ticker 

20 tape 114. In this way, several charts are displayed and 
moved at any instant in time. 

[0064] When the finite number of requested charts 
116 have been displayed (one loop of the ticker tape 
114), the sequence of displaying the charts 116 is re- 
2s peated. However, rather than downloading this informa- 
tion for a second time, the originally received data which 
has been cached is used to generate the sequence to 
be repeated. 

[0065] Each ticker tape chart 1 1 6 is of a fixed time pe- 
30 riod, one year in this embodiment. However in alterna- 
tive embodiments of the present invention, not only can 
this time period be fixed to a different value but also it 
can become a user-definable factor which Is set by the 
user when the desired subject groupings are selected. 
35 [0066] The applet 1 22 also permits a detailed expand- 
ed static display of each chart 116 together with the data 
descriptors of the subject, by the customer simply se- 
lecting the chart 1 1 6 by a mouse click. In order to provide 
the desired static display, with potentially a maximum 
^o level of detail, the mouse click generates a new URL 
which is sent to the local data distribution site 28, 30 to 
access the desired historical data and generate an ap- 
propriate GIF chart 116. 

[0067] How the graphical representation is to be dis- 
45 played is also selectable, for example in the form of a 
line graph, an area graph or a bar graph. Also the cus- 
tomer 38 can select the time period each chart 1 1 6 is to 
cover (one to five years for example) and the granularity 
of the data to be displayed (daily, weekly, monthly for 
50 example). The selected options which relate to the way 
in which the historical data is to be presented, simply 
determine how historical data is to be extracted from the 
second part of the subject records in the securities da- 
tabase 106. 

55 [0068] When the communications server 1 1 0 search- 
es the securities database 106 for a particular subject 
in order to generate its corresponding historical data 
chart 11 6, the access primitives (not shown) used to ob- 
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tain the data from the securities database 106 are opti- 
mised to allow fast access to the relevant data granu- 
larity (daily, weekly, monthly, etc.) and a very fast retriev- 
al of the historical data. This speed is due to the contig- 
uous storage of consecutive historical performance data 
in the securities database 106. 
[0069] The format and operation of the ticker tape 1 1 4 
is now described with reference to Figure 4. The ticker 
tape 114 provides a GUI (Graphical User Interface) for 
the Internet customer 38. The main portion of the ticker 
tape 114 displays moving charts 116, one for each of 
the securities of interest to the customer 38. A smaller 
portion of the ticker tape 114 provides control buttons 
130 which generate, on selection, commands for con- 
trolling the operation of the ticker tape 114 on the cus- 
tomer's screen 1 24. 

[0070] The applet 122 interprets the customer's se- 
lection of a control button 130 as a command and, in 
response, controls the movement of the ticker tape 114. 
For example, the customer can by clicking on the speed 
buttons 132 accelerate and slow down the ticker tape 
speed. Also the direction of scrolling can be changed 
using the directional arrow buttons and even a stop but- 
ton 136 is provided. 

[0071] The customer 38 can also select the type of 
securities that are to be displayed in the ticker tape 114. 
The control buttons 130 include a configuration button 
138 for this purpose. When the customer 38 clicks on 
the configuration button 138 of the ticker tape 114, the 
URL of a specific configuration page is generated. 
[0072] The configuration page presents customer se- 
lectable options for the types of securities that are to be 
displayed. For example, the type of securities to be dis- 
played can be selected by country, region, past perform- 
ance criteria, stock type, etc. The options presented to 
the customer correspond to the data descriptors (group- 
ings) of the first part of each subject record provided in 
the securities database 1 06. The selected options which 
relate to the way in which the historical data is to be pre- 
sented, simply determine how historical data is to be ex- 
tracted from the second part of the subject records in 
the securities database 106. It is the provision of these 
data descriptors that in each subject record which ena- 
ble rapid grouping of relevant data according to a cus- 
tomer's specific configuration. 
[0073] The customer 36 makes a selection and a list 
of the selection criteria of the securities to be included 
in the ticker tape 1 14 is created. This list is then stored 
in the SQL relational database 112 as the specific con- 
figuration information for this customer and is used sub- 
sequently for the generation of each new chart 116 for 
this customer 38. 

[0074] After a customer has configured the ticker tape 
1 1 4, the applet 1 22 restarts the information request pro- 
cedure from the retrieval of the specific configuration in- 
formation. 

[0075] The proprietary components on the server side 
of the above-described embodiment are implemented 
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in the C++ programming language using COM interfac- 
es. 

[0076] Having described a particular preferred em- 
bodiment of the present invention, it is to be appreciated 

5 that the embodiment in question is exemplary only and 
that variations and modifications, such as will occur to 
those possessed of the appropriate knowledge and 
skills, may be made without departure from the spirit and 
scope of the invention as set forth in the appended 

10 claims. For example, it is to be appreciated that the 
above is the presently preferred implementation of the 
present invention. The use of Microsoft™ ASP, ADO, 
MS IIS, COM as well as Java can readily be substituted 
with equivalent technology. It would also be possible for 

is the performance data to be distributed to mobile user's 
telephones using WAP (Wireless Application Protocol). 
This provides a powerful way in which customer's can 
be kept updated with stock market information even 
when not at their desks. 

20 

Claims 

1 . A method of distributing performance data concern - 
25 ing a plurality of subjects from a distribution site to 

a user site, the method comprising: 

storing gathered performance data concerning 
each of the subjects in a central database, 
30 wherein the storing step comprises storing the 

gathered data to form a contiguous sequential 
block of historical data for each subject; and 
on request from the user, providing a stream of 
historical data from the blocks in the central da- 
35 tabase such that a ticker tape of a plurality of 

graphical historical data charts can be dis- 
played at the user's site, automatically and 
without user interaction. 

2. A method according to Claim 1 , wherein the stream 
of historical data is provided as a stream of graph- 
ical data. 

3. A method according to Claim 1 or 2, wherein a rate 
45 of generation of the graphical historical data charts 

corresponds to the speed of movement of the ticker 
tape displayed at the user's site. 

4. A method according to any preceding claim, where- 
50 in the storing step comprises storing the gathered 

performance data In the historical data blocks such 
that each block Is partitioned according to predeter- 
mined different time periods. 

55 5. a method according to Claim 4, wherein the histor- 
ical data blocks are each partitioned in daily, weekly, 
monthly and yearly time periods. 
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6. A method according to any preceding claim, further 
comprising gathering performance data at a central 
site and subsequently updating the distribution site 
with the gathered data. 

7. A method according to Claim 6, wherein the gath- 
ering step comprises downloading performance da- 
ta from a plurality of electronic data vendors where 
two or more data vendors have different data distri- 
bution protocols, and for each data vendor having 
a different data distribution protocol, the method fur- 
ther comprises implementing an appropriate com- 
munications protocol for downloading performance 
data from each data vendor. 

8. A method according to Claim 6 or 7, wherein the 
gathering step comprises consolidating, integrating 
and reformatting gathered performance data from 
the plurality of data vendors. 

9. A method according to any preceding claim, where- 
in the providing step is initiated by a data request 
from the user. 

10. A method according to Claim 9, wherein the request 
includes identity information identifying the user, 
and the method further comprises accessing a user 
configuration file describing a required data config- 
uration for the identified user, or for a newly identi- 
fied user, creating a new user configuration file set 
to a default configuration. 

1 1 . A method according to Claim 10, wherein the com- 
munications network is the Internet and the identity 
information comprises a cookie file initially sent to 
the user. 

12. A method according to Claim 10 or 11, further com- 
prises storing the user configuration files and iden- 
tity information in a relational customer database 
and accessing the same using Structured Query 
Language. 

1 3. A method according to any preceding claim, where- 
in the providing step further comprises sending a 
user configuration file to its user together with a data 
handling function arranged to present to the user 
the historical data in accordance with the user con- 
figuration file. 

14. A method according to Claim 13, wherein the com- 
munications network is the Internet and the data 
handling function comprises an applet. 

15. A method according to Claim 13 or 14, wherein the 
data handling function configures a user's screen 
according to the information in the configuration da- 
ta file and requests specific historical data from the 
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central database for immediate display. 

16. A method according to Claim 15, wherein the pro- 
viding step comprises only supplying specifically re- 

s quested historical data. 

17. A method according to any of Claims 13 to 16, fur- 
ther comprising using the data handling function to 
arrange the historical data into charts and to display 

10 simultaneously a plurality of charts arranged as an 
endless stream of moving graphical images forming 
a ticker tape on a user's screen. 

18. A method according to Claim 17, wherein the step 
is of using the handling function comprises configur- 
ing the user's screen to control the amount and type 
of historical data to be displayed. 

19. A method according to any preceding claim, where- 
to in the storing step is carried out on a daily basis. 

20. A system for distributing performance data con- 
cerning a plurality of subjects from a distribution site 
to a user site, the system comprising: 

25 

a central database of performance data relating 
to each of the plurality of subjects, 
storing means for storing gathered perform- 
ance data concerning each of the subjects in 
30 the central database, the storing means being 

arranged to store the data to form a contiguous 
sequential block of historical data for each sub- 
ject; and 

read out means arranged to provide, on request 
35 from the user, a stream of historical data from 

the blocks In the central database such that a 
ticker tape of a plurality of graphical historical 
data charts can be displayed at the user's site, 
automatically and without user interaction. 

40 

21. A configurable ticker tape interface for providing 
performance data regarding a plurality of subjects 
stored in a remote database, the ticker tape inter- 
face being arranged to be configurable by the user 

4 5 to specify a subset of the plurality of subjects, to ob- 
tain current performance data and historical data 
from the remote database regarding the selected 
subset of subjects, and to generate user-controlled 
movable icons of thetickertape interface, each icon 
so representing the current performance data and his- 
torical data for selected subject in a graphical for- 
mat. 

22. A graphical user interface comprising: 

55 

processing means for obtaining updated infor- 
mation from a distribution database regarding 
a plurality of subjects and processing the ob- 
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tained information to display a moving set of 
graphical images, each image representing 
current performance data and historical data for 
a given subject; and 

selecting means for creating a user selection, 5 
the selecting means being arranged to config- 
ure the processing means to obtain information 
for a selection of the plurality of subjects stored 
in the distribution database. 

10 

23. A graphical user interface according to Claim 22, 
further comprising selection means, operable by 
the user, for selecting a time period of historical da- 
ta, smaller than that stored in the distribution data- 
base for a given subject, which is to be displayed in 15 
the set of graphical images. 

24. A graphical user interface according to Claim 22 or 
23, further comprising control means, operable by 
the user, for altering the movement of the set of 20 
graphical images. 
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